The Scrum Framework: You are doing it wrong!

How should we implement Scrum?

What are various roles and ceremonies of Scrum?

What is Scrum Methodology?

What meetings are required by Scrum?

Scrum is the most popular Agile Framework. Almost every software development team in the world is using some aspects of Scrum framework in some shape or form. However most Scrum implementations that I have seen are missing some crucial parts of the recipe preventing them from achieving the exceptional results promised by Scrum.

I’ve decided to write this article, providing a concise summary of Scrum framework and how I believe it really should be implemented.

What is Scrum?

This is Scrum:

Piece of cake! Isn’t it? Now let’s look at each artefact, role and ceremony in more details:

Product backlog

Product backlog is an ordered list of various work item that needs to be done. These work items are called Product Backlog Items (PBI). Items at the top of the backlog have higher priorities and items at the bottom of the backlog have lower priority. No 2 items have the same priority. Every item has more priority than the item below it and less priority than the item above it. The product backlog is not a queue and can be constantly reprioritised and changed by the product owner.

Items at the top of the backlog are more refined and are more ready for the team to start working on and items lower in the backlog are larger and more abstract. PBIs can be various things including but not limited to requirements (user stories), bugs, Spikes and research tasks, tech debt, etc.

Product Owner

Product owner is the person ultimately responsible for the product. They steer the development by prioritising the work. Product owner has content authority of the user stories. Based on the input from the stakeholders and the product/team vision, the product owner makes decision on the work that needs to be done. Product owner is responsible for defining the “why” and the “what” but not the “how”.

Product owner not the boss of the team, they are just another team member like everyone else. They are however the boss of the product backlog. They own the backlog. They decide what gets built next by prioritising the backlog.

The most important attributes of product owner are:

Domain Expert (e.g. understand the product really well)
Available (e.g. sitting with the team)
Stakeholder manager (e.g. ability to say no to multiple directions)
Empowered (e.g. ability to make important decisions independently)

The best analogy for product owner is “The Doctor” form the “Doctor Who” show.

He has the weight of the world on his shoulder.

He prioritises. Some lives need to be sacrificed to save the universe. And the product owner needs to live with those decisions for the rest of his life.

There is so much on his mind. So many responsibilities, so many balls to juggle. So little time. Needs a TARDIS to go back in time to finish those jira cards just in time.

He has made so many mistakes but at the end of the day he has saved the product and the universe so many times.

He is the best negotiator in the world. Can negotiate Daleks and Iron Men out of blowing up the planet

He knows almost everything. He has breadth of knowledge.

He finds information and provides it in a consumable format.

He is always available any time anywhere. He has a TARDIS.

And most importantly he is empowered to make decisions.

The development team

The development team or the developers are the people who build the product. Developer in the context of Scrum does not mean a computer programmer. It means anyone who participates in the development of the product. For example Programmers, Testers, UX designers, Business analysts, Tech writers, Release Leads, Architects, etc are all developers. Basically everyone on the team except the Scrum Master and the product owner are developers (remember this for your PSM exam).

Developers are responsible for defining the “How”, but they can also contribute and help product owner on the “What” and the “Why”. The Dev team needs to remain stable over long periods of time. We can’t add/remove developers to the team at will.

The best Analogy for the Dev team is the Guardians of the Galaxy.

They are NOT super heroes. They don’t have super powers. Except for maybe Groot.

The have T-shaped skills. Highly skilled at one thing but also a little skilled at a few other things

They may have their differences but they collaborate really well.

They cover for each other.

They may look selfish at first but they are prepared to die for each other.

They all have their quirks, but do the right thing at the end of the day.

And most importantly they do whatever it takes, whatever it takes, to get the job done.

Scrum Master

The Scrum Master is the Master of Scrum. When we say someone is the Scrum Master does it mean everyone else are the Scrum Slaves? No, “Master” here refers to mastery. It means the Scrum Master is highly skilled at Scrum. They are the Scrum Coach for the team. The Scrum Master is the team facilitator and the remover of impediments.

Scrum Masters are servant leaders. It means they lead without having authority, just like Nelson Mandela, Mahatma Gandhi, and many other servant leaders in history. They persuade rather than using authority and lead rather than manage. The Scrum Master is not the boss and the team don’t report to the Scrum Master.

The Scrum Master is more of a “Servant” rather than a “Master”. They need to server the team and make sure the team gets whatever they need to work at optimum performance.

The best analogy for the Scrum Masters are Jedi Knights from the Star Wars Saga

The Scrum Master is the glue for the team.

He has great relationships with everyone.

He is a facilitator.

Makes sure the processes that the team agree upon are followed.

He is the impediment bulldozer.

He users a light-sabre to open up the path for storm developers (storm troopers) to move forward into enemy territory.

He is diplomatic but not political. Witty and clever but righteous.

He travels across the galaxy to facilitate and remove impediments.

And most importantly he uses “the force” to sense impediments before they are even emerged

Sprint Planning

In the Sprint Planning meeting, the team plans for the sprint. The sprint planning is time boxed maximum of 4 hours for 2 week sprints. This meeting happens at the beginning of the sprint. At this sprint we talk about how much work can be done this sprint and how the chosen work will get done.

During this meeting the team starts picking up PBIs from the top of the product backlog. They discuss each item and clarify questions with the product owner. They estimate the PBI if not already estimated and start thinking about implementation on a very high level and not too much in technical details. Then they will move to the next PBI from the product backlog. The team repeats this until they feel they are at capacity.

The work that the team plans to deliver this sprint is called the Sprint backlog. Then based on the work that the team has picked up in the sprint backlog, they construct a Sprint goal.

Finally the team commits to deliver the sprint backlog by the end of the sprint. And the product owner commits not to change anything in the sprint backlog during the sprint. If the product owner makes any changes it will void the team’s commitment.

Note that the Scrum Guide has removed the word “commitment” and replaced it with “forecast”. I personally still prefer to call it commitment rather than a forecast. At the end of the day, every team needs to assess this in their context to see if they are happy to consider the sprint backlog as a commitment or prefer to think of it as a forecast.

Sprint Backlog

As mentioned above the sprint backlog is the plan that the team comes up with for the sprint. The sprint backlog is owned by the developers. The order of items in the sprint backlog is decided by the dev team not the product owner (unlike the product backlog). The product owner cannot make any changes to the sprint backlog. If the product owner needs to absolutely make changes to the sprint backlog in certain circumstances, they will void the commitment/forecast of the team to deliver what they said they will in the sprint.

Backlog refinement

Backlog refinement (A.k.A. Backlog Grooming) is the process of refining and preparing the PBIs for the upcoming sprints. Typically there is a backlog refinement meeting to talk about and estimate the PBIs prior to the sprint planning. The better we prepare and refine the PBIs before the planning meeting the shorter and easier the planning meeting becomes.

Sprint

Sprint is a short timebox where the team refines, builds, and tests PBIs. At the end of the sprint a potentially shippable product implement must be produced. Typically sprints are 2 weeks but it can be really any length, I have seen 4 week sprints, 3 week sprints, 2 week sprints, 1 week sprints and even 2.5 day sprints. It is a decision that needs to be made according to the context.

Not that once we set the sprint length we don’t want to change it and we want to keep the cadence.

Every sprint the team iterates and goes through the same process again, incrementally delivering potentially shippable product increments.

Daily Scrum

Daily Scrum or Daily Standup is a short meeting that happens every day while standing up next to the team kanban task board. The Daily stand-up is timeboxed to maximum of 15 minutes but ideally you want to finish your standup in 5 minutes.

The daily Scrum is not a problem solving venue. Neither is a status update. The daily Scrum is a venue primarily for identifying impediments. It is also a venue for confirming if we are still on track with achieving the sprint goals.

There are 3 questions that everyone needs to answer in the daily stand up:

– What did I do yesterday?

– What will I do today?

– do I have any impediments?

The daily Scrum is followed by a meet after in case some people need to discuss anything specific or get into more detailed conversation

It is quite common that developers decide if they are going to pair with anyone during the standup.

Potentially shippable product
increment and the definition of done (DoD)

Each team will have a definition of Done (DOD). This is to align what done means. So we are not going to have conversations like is it done or is it done done?

The team needs to write the DoD, print it, and put it on their wall. The DoD defines what a potentially shippable product increment means. Ultimately Done in Scrum means released to customers. However in most cases it is not practical to release to customers within each sprint. For a start, most teams do not have continuous delivery pipeline. Even if they did have it, deployed to production does not necessarily mean released to customers. This is because typically there are other activities such as documentation, customer communication, marketing, compliance and many other activities that need to be done before new features are released to customers.

The “potentially shippable” in potentially shippable product increment is referring to this. That shipping the product is a business decision. The team needs to make sure it is potentially shippable and the business makes the call to ship it or not.

One very common Definition of Done that I see all the time is deployed on staging and approved by product owner. However Scrum teams need to strive to move their done to mean released to customers. Over time they need to bring those extra activates within the sprint and the capabilities of the team to make sure they can go all the way until value is realised by the customer and only then call it done.

Sprint Review

The sprint review is the event that the team (including the product owner) demo the work they have done during this sprint to a wider stakeholder group. The primary purpose of sprint review is to inspect and adapt the product and get feedback from the wider stakeholder group.

Now let be quite clear. Sprint review is not just a “showcase”. Please stop calling sprint review “showcase”.

Calling sprint review a showcase trivialises the review to a just a demo rather than a collaborative session where stakeholders provide feedback. It is a review of the potentially shippable product increment not a showcase of what we did in the sprint.

Sprint retrospective

This the event where the team focuses on themselves and the process. They inspect and adapt the previous sprint. During the retrospective the team looks at the sprint and brainstorm on what to keep and what to change. Every retro needs to have 1-3 actions. The teams need to come up with experiments and implement them. Then review their experiments in future retro. We want to inspect and adapt in short small cycles that is why we do a retro every sprint.

Scrum theory

Scrum is based on empirical process control theory. Empiricism is what the scientific method is based on. It means in scrum every opinion remains a hypothesis until it is validated.

In order to have empirical process control we need to have transparency, inspection and adaption. It means we come up with hypotheses, we keep a transparent environment, we inspect, and based on our learning, we adapt.

Scrum is designed in a way to maximise transparency, inspection, and adaption. Ken Schwaber, one of the original creators of Scrum, puts it this way: Scrum is like your mother-in-law, it points out all your faults.

The Scrum Core

This diagram depicts what is at the core of Scrum.

I made this diagram based on what I learned from Alistair Cockburn from his heart of agile course. I have tweaked and adapted it a little.

This is all it comes down to. Do this and you are doing it right, don’t do this and you are doing it wrong.

In my opinion, if you are missing any of the 4 items at the core of Scrum, you are not doing scrum.

If you have stand-ups and sprint planning, and all the details of the framework but you are not delivering or demoing every sprint you are not doing scrum.

If you are highly efficient and your velocity has improved 10 fold in the past quarter but you are not focusing on the highest value first you are not doing Scrum.

If you are following all the rules of the scrum guide but your testers are all offshore and programmers need to do a handover to them you are not doing scrum.

If you are delivering working software every sprint and your customers are happy and it’s all rainbows and butterflies but you are not making changes based on your retro actions you are not doing Scrum.

So make sure to focus on highest business value first, deliver (or demo) every sprint, have a cross functional team, and inspect and adapt every sprint. The rest are peripherals.

We should get the basics right first then move to the details. Focus on the core always while you are implementing the various scrum artefacts, roles, and ceremonies. And make sure you evaluate everything with these principles.